Pinging @elastic/es-core-infra (Team:Core/Infra)

The LogsdbIndexModeSettingsProvider already injects private settings:
https://github.com/elastic/elasticsearch/blob/main/x-pack/plugin/logsdb/src/main/java/org/elasticsearch/xpack/logsdb/LogsdbIndexModeSettingsProvider.java#L143

I'm probably missing something here..

Looks like we're skipping adding the private settings during template validation via this hack:

I'd rather have the template validation work on the actual settings than the provider behaving differently during validation.

Like @dakrone I'm a bit worried that we have three different names for what appears to be the same concept:

• "additional settings"
• "system provided settings"
• settings from an IndexSettingProvider

I think we should either use the same name everywhere, or else very clearly define the differences between these concepts.

The thought process behind it was that CreateIndexClusterStateUpdateRequest and MetadataCreateIndexService#validatePrivateSettingsNotExplicitlySet don't need to know about index setting providers, and I didn't want to restrict the concept of "system-provided settings" to just settings that come from an IndexSettingsProvider, even though that's currently the only source. Renaming the signature

getIndexSettingsValidationErrors(
    final Settings settings,
    @Nullable Settings systemProvided,
    final boolean forbidPrivateIndexSettings
)

to

getIndexSettingsValidationErrors(
    final Settings settings,
    @Nullable Settings additionalSettings,
    final boolean forbidPrivateIndexSettings
)

to match the naming in MetadataIndexTemplateService#validateIndexTemplateV2 seems to decrease clarity. What are these additional settings? IMHO systemProvided is more expressive.

The main concern of MetadataIndexTemplateService#validateIndexTemplateV2 is to collect additionalSettings from IndexSettingsProvider#provideAdditionalSettings, which also get passed in to MetadataCreateIndexService.validateAdditionalSettings. Therefore, renaming additionalSettings to systemProvidedSettings doesn't seem to increase clarity and uniform naming unless we also rename IndexSettingsProvider#provideAdditionalSettings and MetadataCreateIndexService.validateAdditionalSettings which I'm assuming we don't want to do.

What do you think about calling it consistently additionalSettings in the context of MetadataIndexTemplateService (which is where the additional settings get collected) and systemProvided in the context of MetadataCreateIndexService (which is where the validation of private settings is happening).

Personally, I still like it the best as-is. But I'm definitely not married to a particular name and I'm happy to rename to something y'all feel more comfortable with. This doesn't seem like a make or break kind of decision. So let's align on something so that we can move on.